This invention relates to a conversion declaration for use in upgrading source code of a program and to a programming compiler for implementing conversion declarations.
Most high level programming languages used in writing large software programs (e.g., JAVA, C, C++, COBOL, FORTRAN-IV, FORTRAN-90, ADA, PL/1, MODULA-2, MODULA-3, EIFFEL, ML, HASKELL, SATHER) have a type system and are statically compiled in compilers which check types and usages (i.e. semantic usages) at compile time. A "type system" means that each variable in the program has a type associated with it. Example types are integers, floating point numbers, and characters. It is often necessary to upgrade such a software program. To facilitate this process, text-based pattern matching and substitution systems are known. However, such systems have a number of drawbacks which may be highlighted by considering the following C code fragment:
01 { int my_var = 7; 02 03 struct MS { 04 float my_var; 05 char code; 06 } my_struct; 07 08 my_struct. 09 my_var = 12.0 + my_struct.my_var; 10 11 { char my_var = `M`; 12 char other_var = my_var + trunc(my_struct.my_var); 13 struct MS *my_var_ptr = &my_struct; 14 if (my_var_ptr-&gt;my_var) printf(stdout, "non- zero\n");
A text-based pattern matching and substitution system cannot distinguish among the three different variables named my_var, declared on lines 01, 04, and 11, without heroic efforts. That is because the semantics of an identifier can be highly diverse within a single program in almost any high-level programming language.
A text-based system also has considerable difficulty distinguishing between the two different kinds of accesses to my_struct.my_var on line 09: the first occurrence is a write access, and the second is a read access.
A text-based system cannot tell that the expressions my_struct.my_var on line 09 and my_var_ptr-&gt;my_var on line 14 are denotationally identical (except possibly for the structure instance affected), because they do not `look` alike.
Similarly, a text-based system cannot easily distinguish among expressions by type: for example, it cannot readily recognize that on line 12, my_var is a char-valued expression (that is, it is a character type expression), whereas trunc (my_struct.my_var) is an int-valued expression (that is, it is an integer valued expression).
Another problem area for text-based pattern matching and substitution is that, due to the lack of type- and usage- checking associated with text-based substitutions, the changes made in the program text must be checked by responsible, expert programmers. This creates two difficulties:
1. Checking is significant work for the responsible expert programmers, especially where the program is large and the changes are not isolated to a small portion of the program.
2. The text delta (list of changes in the program text) may be very large, even where (semantically speaking) what is happening is simply a specific change which could be stated, in English, in a sentence or two. (For example: "Change all read references to data_base_index to current_env.data_base_index. Change all write references to data_base_index from data_base_index=Newvalue to log_update(data_base_index,NewValue.")
This makes tracking the system changes a huge job: it hides individually significant changes by burying them in masses of stereotyped changes.
A final problem area for text-based pattern-matching and substitution systems is that they are not scoped in the same way as normal program entities. Consider, for example, the following C code fragment:
 01 extern int K; 02 #define incr(X) (X += K) . . . 03 void next_step (double J,K) { 04 { 05 int count = current_count; 06 incr(count);
(The " . . . " represents omitted material.)
If a programmer wrote code along the above lines, then the effect of the call to the incr macro on line 06 would almost certainly not be what the programmer intended. Its effect, as written, would be to increase the value of the local count variable by the value of the double parameter, K. However, from the declaration context on lines 01-02, it appears that the intent would be that count should be incremented by the value of the extern int K.
The problem is that the scope of macros is entirely different from that of ordinary declared program entities (variables, constants, routines, types, etc.). Here, the handling of incr is done by the C pre-processor (cpp) which uses a completely different processing strategy from the C compiler proper, and takes no cognizance of C scoping rules.
This invention seeks to overcome drawbacks of prior software upgrading systems.